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@ PROCEDE DE GENERATION AUTOMATIQUE D'UN 
D' ADMINISTRATION DE RESSOURCES INFORMATIQUES. 

Le precede de g^n^ration automatique d'un module 
(19) (fuoe base d'Informations d'admtntstration (MIB) d'une 
ressource informatique (11) representee par objets ^ in- 
duant une architecture d'objets cfistiibues (CORBA) selon 
un langage donnd (IDL). consiste ^ former un fichier (100) 
d'un fichier de description (101 ) et d'un fichier (102) de clau- 
ses de generation automatique. une c^use comprenant au 
moins un mot de determinant un mode de generation et au 
moins une caractehstique sur laquelle porte un mot cie, et ^ 
appllquer le fichier (100) ^ des moyens de generation (52. 
54) pour obtenir le module. 
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Titre 

Precede de g6n6ratioii d'un module d'une base dHnfonnations 
d'administration de ressources inforaatiques. 

s Domaine technique. 

L*invention concerne radministration d'au moins une ressouicc 
informatique representee dans une technologie orient6e objets. La ressource 
informatique peut etre un systeme informatique et/ou un r6seau informatique 
et/ou une application informatique. Linvention a pour objet un proced6 de 
10 generation automatique d'un module d'une base d-informations 
d'administration d'un tel systeme. La generation d'un td module impUquant 
la modification des agents d'administration utilisant ladite base et d'un 
integrateur de ces agents, l-invention s'applique aussi k la generation 
automatique d'un tel integrateur d'agents d'administration. 
15 L'invention est plus particulierement adaptle k un systeme 

informatique induant une architecture d'objets distribues, telle que 
I'architecture CORBA (Common Object Request Broker Ardiitecture) d6finie 
par le groupement de foumisseurs et d'utilisateurs travaiflant k U 
normalisation de la gestion des objets et connu sous le nom OMG (Object 
20 Management Group) et I'architecture OLE/COM (Object Linking and 
Embedding / Component Object Modder) de Microsoft. L'architecture CORBA 
sera prise comme exemple non limitatif dans la suite du texte. Dans le 
domaine de l-informatique distribuee. I'architecture CORBA permet de 
decrire des interfaces de services informatiques indepcndamment des 
25 foumisseurs et des langages mettant en oeuvre ces services. La description 
des interfaces est faite k I'aide d'un langage neutre de description d^interface 
connu sous le nom de langage IDL (Interface Definition Language) defini 
aussi pap le groupement OMG. Ce langage definit les fitontieres d'un 
composant qui constitue un objet ger6, c'est4-dire les interfaces 
30 contractuelles du composant avec des clients potentiels. 
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Linvention a aussi pour objets coroUaires le syst^me 
d'administration et le syst^me informatique qui mettent en oeuvre le proced6. 

L*art antirieur. 

L'adxninistration de ressources infonnatiques est ordinairement 
faite par une plate*forme logidelle d'adminiatration dont on connait plusieurs 
types. La plate*forme qui servira d*exemple par la suite est cdle connue sous 
le nom de marque d6pos6e OpenMaster, commercialism par le demandeur. 
Cette plate-forme se fonde sur une technologie k objets* Selon cette 
technologies les moyens constituant la ressource informatique sont convertis 
en classes d'objets organis6es liierarchiquement dans une base dHnformations 
d'administration MIB (Management Information Base). L'invention 
s*applique k la g^n^ration d'une partie, nommee module, de cette base. 

D*autre part, la plate-forme servant d*exemple utilise le protocole 
normalise de communication dedie k Tadministration connu sous le nom de 
protocole CMIP (Common Management Information Protocol). Le protocole 
CMIP repose sur la norme ISO definissant les services pour le transfert des 
informations d'administration appeles services CMIS (Common Management 
Information Services). Ce protocole est organist selon un langage de 
description des informations d'administration appele langage GDMO/ASN.l 
issu de directives pour la definition d'objets gerte (Guidelines for the 
Definition of Managed Objects) selon le mod^e dHnterconnexion connu sous 
le nom de marque d^pos^ OSl (Open Systems Interconnection) de 
I'organisme international de normalisation ISO (International Standards 
Organisation), et de syntaxe ASNl (Application Syntax Notation One). Pour 
des raisons de commodite, ce langage sera appele simplement GDMO. 

Un probldme se pose quand Tadministration de ressources 
informatiques au moyen de cette plate-forme utilise une architecture d'objets 
distribu^ teUe que CORBA. Cette administration conceme non seulement 
I'architecture CORBA elle-meme» mais aussi les services d*applications 
coop^rant avec cette architecture. Ces services peuvent etre administres par 
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I'intermediaiie d'une interface d'administratioii publiie. dfcrite dans le 
langage IDL de I'architecture CORBA. A partir d'une description en langage 
IDL d'une interface d'un service CORBA^un compilateur IDL g6n6re dans un 
langage de programmation. par exemple C++, du co4e dont une partie. 

5 connue sous le nom normalise "skeleton", pennet de mettre en ceuvre le 
service et dont une autre partie, connue sous le nom normalise "stub", permet 
d'appder le service k partir d'un autre programme sous forme de 
bibliothdiiue. L'agent mis en ceuvre comme service particulier de CORBA a 
done une interface d&rite en langage IDL. Cette description est aussi la 

10 description de l-information d'administration ofFerte par l'agent. U langage 
IDL sert ainsi k la fois de langage de description d'interface et de langage de 
description dinformation d'administration. 

Le procMe de generation automatique d'un module d'une base 
d'informations d'administration d'une ressource informati<iue representee par 

15 objets et induant une architecture d'objets distribute CORBA selon le 
langage IDL, consiste actuellement k faire un fichier de description 
d'interface dans le langage IDL, k faire une conversion automati<iue du 
fichier et k compiler le fidiier de description pour obtenir le module. 

Plusieurs algorithmes de conversion sont connus, tels qpxe ceux 

20 publics par le groupe JIDM (Joint Inter-Domain Management) du groupe 
ORG. Cependant, ces algorithmes ne su£Bsent actuellement pas pour obtenir 
une version complete et exploiuble en langage GDMO d'un module de la base 
MIB. Le probieme est que des notions conceptuelles pouvant etre d^crites en 
langage GDMO ne peuvent pas I'etre en langage IDL. Par consequent, on 

2S n'obtient qu'une partie seulement du module desire de la base MIB. 

La solution actuelle consiste k completer manueUement le code 
genere par la conversion, de fagon k utiliser au mieux les caracteristiques du 
langage GDMO. Cette solution a done comme premier inconv6nient d'etre 
couteuse en temps et en argent De plus, ce travail manuel doit etre reproduit 

30 apres chaque traduction dans le cas de changements du contenu du fichier de 
la description rendu disponible par un agent CORBA. C'est done une solution 



2793908 



•4- 

ponctuelle, qui doit etre revue et completee pour etre adaptee a chaque cas et 
qui a pour second inconvenient d'etre limitee au cas d'espdce et d'etre 
d*autant plus couteuse quil y a de changements de la description. Or, 
revolution de cette technologie est rapide et s'avdre done tr6s couteuse. Le 

5 troisieme inconvenient est du au fait que le fichier de description en langage 
IDL est traite par un compilateur, qui oblige la modification de la syntaxe du 
langage IDL. La syntaxe est ainsi alteree dans le seul but de la faire passer 
dans un generateur ext^rieur k Tarchitecture CORBA. 

La generation d'xrn module de base MEB implique directement la 

10 modification des agents d'administration qui servent de liens entre 
Tarchitecture CORBA et la plate-forme d'administration, ainsi que le 
composant servant dHnterface entre ces agents et la plate-forme et appeie 
integratexir d'agents. Le meme fichier de description IDL est utilise pour 
modifier les agents et I'integratexir de ces agents. Alors que la modification 

15 des agents ne pose pas de probldme, la modification de I'integrateur d*agents 
CORBA pose le meme probleme que celui expose precedemment. 

Sonounaire de rinventioQ. 

Un premier but de linvention est de generer automatiquement 
20 dans une base d'informations d'administration MIB un module plus complet 

que celui foumi par la conversion automatique actuellement disponible, le 

module desire etant suffisamment complet pour etre exploitable pour 

Tadministration. Le module genere peut etre nouveau ou resulter d'une 

modification d^m module anterieur. 
25 Un second but est de generer un module de base MIB exploitable 

sans alterer le fichier de description IDL. 

Un troisidme but est de generer un module de base MIB 

exploitable et fadlement adaptable aux changements de la description 

initiale. 

30 Un quatrieme but est de generer simplement et k moindre cout 

un module de base MIB exploitable. 
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Un dnquieme but de I'inventioii est, comme consequence de la 
g6n6ration du module d'administration, de modifier automatiquement 
llntegrateur d'agents d'administration sans intervention manuelle. 

L-invention a pour objet un proced6 de g6n6ration automatique 

5 dnm module d'une base dHnformationa d'administration (MIB) d'une 
ressource informatique representee par objets et induant une architecture 
d'objets distribu6s (CORBA) selon un langage donn6 (IDL), consistant k faire 
un fichier de description d'interface dans le langage donn6 et k appliquer 
ledit fichier 4 des moyens de g6n6ration automatique pour obtenir une partie 

10 dudit module, caract^ris6 en ce qu*a consiste 4 ajouter audit fichier de 
description un fichier de clauses de generation automatique, une clause 
comprenant au moins un mot determinant un mode de generation et au 
moins une caracteiistique sur laquelle porte un mot de, et k appliquer le 
fichier de dauses auxdits moyens de generation pour completer ledit module. 

15 Accessoirement, le fichier de dauses et le fichier de description 

ne forment qu'un seul fichier, l^un des deux fichiers etant distingue de I'autre 

par une marque. 

De meme. les moyens de generation comprennent en outre un 
generateur (54) pour la generation automatique d'une partie d'un integrateur 
20 d'agents d'administratiim. 

L'invention a auasi pour objet un ystime d'administration d'une 
ressource informatique representee par objets definis dans une base 
d'informations d'administration (NOB) induant un module, la ressource 
informatique induant une architecture d'objets distribues (CORBA) selon un 
25 langage donne (IDL), caracterise en ce qu"il met en oeuvre ledit precede. 

Presentation des dessins. 

- La figure 1 est une vue synoptique d'un syst^me 
d'administration d'un systeme informatique, le syst^me d'administration 
30 mettant en oeuvre un procede de generation automatique d'un module d'une 
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basc MIB et du proced6 en resultant pour la g6n6ration automatique d'un 
integrateur d'agents d'administration. 

- La figure 2 est une vue synoptique detaillee de la structure 
d\ine plate-forme d'administration du systeme d'administration repr6sent6 

5 sur la figure 1. 

- La figure 3 est une vue schematique d'un arbre repr6sentetif 
d'un exemple de base MIB correspondant au systdme informatique repr^nte 
sur la figure 1 et incorporant le module a gen6rer conform^ment k llnvention. 

- La figure 4 est une vue schematique d*une architecture d'objets 
10 distribues CORBA en liaison avec un integrateur d'agents CORBA de la 

plate-forme representee sur la figure 2. 

- Et la figure 5 est un organigramme illustrant schematiquement 
le precede de generation automatique d*un module de base MIB» ce precede 
etant aussi utilise pour la generation automatique de llntegrateur d'agents 

1 5 CORBA represente sur la figure 4. 

Description detaillee d*exemples illustrant Tinvention. 

La figure 1 represente un systeme d'administration 10 d'un 
systeme informatique 11. L'exemple qui suit se rapporte au systeme 

20 d'administration et de securite connu sous le nom de marque deposee 
OpenMaster du demandeur. Sa conception est conforme aux normes ISO de 
I'administration de systemes et reseaux. Dans ces conditions, les termes 
utilises seront conformes k cette norme, qui sont de langue ang^aise, 
notamment les sigles et acronymes. D'autre part, les verbes "admimstrer" et 

25 "gerer" et leurs derives qui seront employes id txaduisent tous deux 
indifferemment le verbe an^ais "manage" et ses derives. Lliomme du metier 
connait bien ces normes. Compte tenu de leur masse informative, on ne 
donnera id que les elements necessaires a la comprehension de IHnvention. 

Le systeme informatique iUustre 11 est distribue et compose de 

30 machines 12 (12a, 12b) organisees en un ou plusieurs reseaux 13. Une 
machine est une unite conceptuelle tres large, de nature materielle et 
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logidelle, pouvant etre les moyens impliques pour ex^ter une application 
donn^, des moyens pour ex^uter une fonction donn^, un ordinateur, ainsi 
qu'un systdme infonnatique dans une architecture k systdmes en cascade. Les 
machines 12 peuvent etre done tres diverses, telles que stations de travail, 

5 serveurs» routeurs, machines specialisees et passerelles entre r6seaux. Le 
systdme infonnatique 1 1 est ordinairement un syst^me comprenant plusieurs 
processeurs 14, un processeur 14 etant par exemple illustr6 dans chaque 
machine 12, des moyens de memoire 15 pour contenir les logidels et les 
donnees du systeme, et des moyens d'entree-sortie 16 servant pour la 

10 communication entre machines par I'intermediaire du r^seau 13 a Taide de 
protocoles divers, ainsi que pour une ou plusieurs communications 
exterieures, par exemple pour limpression, la telScopie, etc. Un tel systdme 
peut par exemple g^rer des donnees k distance, distribuer des donnees dans 
le cas d*un syst^me de reservation, commander Tex^tion de programmes k 

15 distance sur des machines sp6cialisees, partager localement des ressources 
physiques ou logidelles, et communiquer, 

Le syst^me d*administration 10 a une architecture de type dient- 
serveur. Dans Texemple illustre, les unites formant clients et serveurs dans le 
systdme d^administration 10 comprennent deux gestionnaires 17a formant 

20 serveurs et trois agents 17b formant clients. Une machine 12 induant un 
gesdonnaire est dite machine gestionnaire ou serveur 12a et une machine 
induant un agent est dite machine geree 12b ou diente. Les gestionnaires 
17a et les agents 17b sont relies entre eux par IHntermediaire du r^au 13. 
Dans Texemple illustr6, les deux gestionnaires sont relies entre eux, Tun des 

25 gestionnaires 17a 6tant relie k deux des agents 17b tandis que I'autre est 
relie a\ix trois agents. Les liaisons entre gestionnaires et agents peuvent etre 
tr^s diverses. D'autre part, les communications entre gestionnaires et agents 
peuvent se faire selon un ou plusieurs protocoles, de prefi^rence normalises 
tels que les protocoles CMIP (dej^ dt^) et SNMP (System Network 

30 Management Protocol). Le protocole CMIP repose sur la norme ISO 
definissant les services pour le transfert des informations d'administration 
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appeles services CMIS (Common Management Information Services). Chaque 
protocole est organise selon un langage de description des informations 
d'administration. Par exemple, le protocole SNMP utilise le langage SMI 
(Structure of Management Information) tandis que le protocole CMIP utilise 

5 le langage GDMO/ASN. 1 d6ji cit6, et simplement appel6 GDMO. 

La figure 2 illustre la structure d'une plate-forme 
d'administration 20 du systeme d'administration 10. La plate-forme 20 peut 
etre limits k une machine gestionnaire 12a. ou etre distribute parmi 
plusieurs machines gestionnaires. Pour des raisons de commodity, la plate- 

10 forme iUustrte dans la figure 2 sera limitte 4 une machine gestionnaire 12a 
et correspond ainsi au gestionnaire 17a. La plate-forme illustrte 20 se 
compose de dnq blocs fonctionneb : un bloc 30 d'applications en langage SML 
(Systems Management Language), un bloc 40 de services, un bloc 50 
d'integrateurs d'agents, un bloc 60 d'inteiface de gestionnaire, et un bloc de 

15 communication 70. 

Le bloc 30 d^applications indut un ensemble d'applications de 
base 31 (core applications), une interface graphique d*utilisateur 32 appeiee 
interface GUI (Graphic User Interface), un tableau de bord constituant un 
lanceur d'applications 33, une interface 34 de communication exterieure du 

20 bloc 30, et un ensemble 35 de fonctions de haut niveau. Dans Texemple choisi, 
les applications 31 sont torites dans le langage SML et communiquent avec le 
bloc 70. utilisant le protocole CMEP et le langage GDMO, par interface 34 
qui est done id une interface SML/GDMO. L'interface GUI 32 permet k un 
utilisateur de se connecter 4 la machine 12a pour d^marrer et arreter comme 

25 il le dSsire ses propres copies des applications de base 3L Le lanceur 
d'applications 33 presente un tableau representant les applications 31 sous 
forme generale par leur nom et/ou, comme dans I'exemple choisi, sous forme 
d'icdnes. 0 suffit de diquer sur Hcone choisie pour lancer Tapplication 
correspondante. Les fonctions de haut niveau 35 sont ajout^ pour offirir des 

30 fonctions particulidres et des interfaces graphiques correspondantes. 
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Le bloc 40 comprend plusieurs services, notamment un service 
41 de base de donnees CMIS. appele service CMIS-DB, un service 42 de 
schemas d'informations d'administration ou service MISS (Management 
Information Schema Service), un service 43 de journal dialarmes et un service 

5 44 de journal d'iv^nements normalement connecte k un journal d'ev6nements 
non illustr6. Le bloc 50 illustre contient seulement un int^grateur 51 d'agents 
d'administration, appel^ ordinairement par le sigle AI (Agent Integrator) et 
affecte k un protocole particulier, id le protocole CORBA, d'autres 
int^grateurs d'agents pouvant exister pour le protocole SNMP, etc le 

10 protocole CMIP est utiUs^ comme exemple dans la plate-forme 20. 
L'int^grateur 51 d'agents est connect^ au bloc 70 et k un ou plusieurs agents 
17b fonctionnant sous le protocole correspondant, id CORBA. Dans I'exemple 
illustre, le bloc 50 indut aussi des moyens de g^n^ration 52, 53 et 54 et des 
moyens de compilation 55 qui, d'une manidre gin&rale, pourraient etre 

15 contenus dans une partie quelconque de la plate-forme 20. Le bloc d'interfacc 
60 permet k la plate-forme 20 de communiquer avec un autre gestionnaire 
17a du systdme 10. pouvant etre un supragestionnaire de niveau 
hi^raxduque sup^rieur. Enfin, le bloc de communication 70 constitue un lien 
entre les autres blocs et est appele courtier de requetes CMIS ou distributeur 

20 CMIS (CMIS Di^atcher). D contient un routeur 71 d'^6nements, permettant 
aux composants d'administration de sousczixe k des notifications 
d'6v6nement, un routeur 72 de commandes pour transmettre des requetes au 
composant destinataire et eviter aux applications de savoir quel composant 
"poss^e" chaque instance MOI, une infrastructure de s^cuxit^ 73, un 

25 gestionnaire 74 d'objets sous la radne ROOT (R(X)T Object Manager), et une 
horloge 75 (timer). 

Selon une option courante et avantageuse du systdme 
d'administration 10, un gestionnaire 17a gere aussi la machine gestionnaire 
12a correspondante ou gere tout ou partie des machines gestionnaires. CelA 

30 pent se faire de fagon similaire a celle illustree pricedemment, plus ou moins 
adapts k cette option. L'exemple illustre ofifre le double avantage de fadliter 
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la lecture des dessins tout en pennettant a rhomme du metier de faire une 
generalisation du systeme decrit et iUustre. 

Le systeme informatique 1 1 de la figure 1 se compose de moyens 
materiels ou logidels, r6els ou virtuels, tels que madiines, imprimantes, 

5 circuits virtuels et applications. Le systeme d'administration 10 utilise ces 
moyens selon un modele de donnees oriente objets, dont on connait les 
prindpales caracteristiques : classes, objets, heritage, encapsulation, 
methodes (id actions) et evenements. ^organisation des dasses dans 
Texemple choisi du systeme 10 est hierarchique. On distingue : I'arbre des 

10 dasses, une dasse etant definie en subordination k une ou plusieurs dasses 
mdres ; et Tarbre des instances, une instance etant attachee ^ une ou 
plusieurs instances mdres. En particulier, une dasse est definie par des 
caracteristiques nomm6es attributs, tels qu'un nom d'un composant du 
systeme et un etat dimpression. Un objet d'une dasse sera appele une 

15 instance de la dasse. Dans Texemple choisi, les moyens du systeme 
informatique 1 1 sont done convertis en dasses d*objets organis^es 
hi^rarchiquement dans une base d*informations d'administration MIB 
(Management Information Base). Cette base n'est pas une base de donn^ 
proprement dite, mais est assimilable k un catalogue de caracteristiques 

20 puisqu'elle contient la description et le contenu de toutes les classes ger^es 
par le systdme d'administration 10. Dans la base MTO, les objets sont divises 
en dasses d'objets g^res, dites dasses MOC (Managed Object Class). Un objet 
gere est une vue abstraite, definie pour les besoins de la gestion, d*une 
ressource logique ou physique d'un ^^yst^me. Chaque dasse MOC represente 

25 un type donne desdits moyens du systeme 11. A chaque dasse MOC peuvent 
etre attachees une ou plusieurs instances d'objets g^rds, appelees instances 
MOI (Managed Object Instance) et representant des occurrences actuelles 
desdits moyens. 

La figure 3 illustre un exemple de structure d\ine base MIB. EUe 
30 a une structure arborescente, faite d'lme radne ROOT k laquelle sont 
attaches des sous-arbres ou sous-MIB 18, id representatifs des trois machines 
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gerees 12b appelees Mac-a, Mac-b et Mac-c. Les sous-arbres 18 sont auaai 
repr^aentes sous forme synoptique dans la figure 1, en Uaison avec les agents 
17b respectife. La racme ROOT est contenue dans le gestionnaire 74 et les 
radnes des sous-arbres seront appelees sous-radnes correspondant au terme 
3 anglais RooUet Ainsi, toute appUcation 31 devant traiter un objet de la base 
MIB s'adresse au gestionnaire 74 pour acceder k I'objet Dans I'exemple 
iUustr*, on a suppose que diaque machine 12b a. comme repr^sente sur la 
figure 1. trois cartes 19, 4 savoir une carte-rfoeau R. une carte vid6o V et une 
carte-son A. de sorte que chaque sous arbre 18 correspondant contient les 
10 trois objets correspondants. Dans la figure 3. seul le sous-arbre 18 relatif k la 
madiine Mac-b a et6 d6veloppe. On y voit que le sous-arbre 18 a U sous- 
radne Mac-b induant trois fils constitues par les trois objets rcspectife carte- 
reseau. carte video et carte-son (R. V et A). Linvention s'appUque i la 
g6n6ration automatique d'une partie de I'arbre. appd6e module 
15 dlnformations d'administration 19 et faite d'au moins un objet g^r6 MOC et 
dont la description en langage IDL est issue d*un agent CORBA 51. Le 
module est d6fini de fa<^n abstraite par un trait fant6me dans la figure 3. 
L'invention a pour objet un proc^de de gto^ration automatique d'un module 
19 k partir d'un fichier de description en langage IDL. ce pK)c6d6 6tant mis en 
20 oeuvre dans un int^grateur d'agent 5 1 . 

Une instance dans la base MIB a un nom distinctif relatif RDN 
(Relative Distinguished Name) sous forme d'une liste d'assertions sur valeur 
d'attribut appelees assertions AVA (Attribute Value Assertion). Chaque 
assertion AVA est un couple ottribut de nommage> <valeur>. I'attribut de 
25 nommage etant cclui qui, dans la dasse, pennet identification unique d'une 
instance par rapport k son instance m6re. Dans un gestionnaire 17a de 
I'exemple illustr*, un nom RDN est compost d'une seule assertion AVA. done 
d'un seul couple <attribut de nommage> <valeur>. D'une manidre g6n6rale. il 
est cependant possible qu'un nom distinctif RDN ait plusieurs assertions 
30 AVA. Chaque instance dans la base MIB est identifite de fagon unique par 
son nom distinctif DN (Distinguished Name), qui est la suite des noms RDN 
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sur le chemin entre la radne et I'instance dans I'arbre des instances. Un sous- 
arbre dhine instance correspond a I'ensemble form6 par I'instance elle-meme 
et les instances qui lui sont subordonn^es dans I'arbre des instances. 

Sous la radne ROOT de la base MIB eat attach^e une sous- 

5 radne pour cbaque service du bloc 40. Dans ce bloc le service CMIS-DB 41 
foumit une base de donn^es des objets g6r6s MOI destin^ k leur persistance 
une fois que le gestionnaire a 6t6 mis hors fonctionnement. n supporte toutes 
les dasses MOC des services CMIS qui sont stock6es localement dans une 
base de donn6es. En outre, a foumit un ensemble de services ou fonctions de 

10 base, appelees aussi primitives, disponibles pour toutes les applications. Ces 
fonctions sont bien adaptees a la structure hierarchique de la base MIB. EHes 
induent notamment les fonctions : M-GET pour lire une ou plusieurs 
instances, M-SET pour mettre a jour une ou plusieurs instances. M-CREATE 
pour creer une instance. M-ACTION pour activer une operation spSdfique 

15 sur une ou plusieurs instances et M-EVENT pour envoyer un ^inement. Ces 
fonctions supportent les notions de filtrage o£frant la possibilite de filtrer les 
instances selon certains criteres portant sur leurs attributs et les notions de 
port^ (scope) permettant de predser le niveau de profondeur dans I'arbre des 
instances. 

20 Le service MISS 42 foumit les moyens d'identification des objets 

g6r6s. les moyens 6tant ceux definis initialement dans les documents de 
definitions GDMO contenus dans une description GDMO. II permet 
d'ex^ter des processus de description pour entrer un nouveau jeu de 
definitions en utilisant un compilateur GDMO et des processus de recherche 

25 (retrieval processes) pour savoir comment une information d'administration 
antirieurement entrte pent etre lue par n'importe quel composant de la 
plate-forme 20. Ces deux processus partagent une base de donnees appel^e 
base de schemas d'informations d'administration, souvent abreg^ en base de 
schemas ou base MISB (Management Information Schema Base). EUe sert au 

30 stockage de tous les jeux correctement compile des definitions d'informations 
d'administration. La base est modelisee par une base MIB. C!ela signifie que 
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la structure de llnformation contenue dans la base de sch^mas est 
logiquement vue comme une base MIB et qu'eUe utilise elle-meme la notation 
GDMO. Cette vue logique de la base de sch^mas est une partie de la base 
MIB giobale accedee par la plate-forme 20 et est appelee base MIB de 

S schemas dlnformations d'administration. 

Les mtonismes et modalites d'echange entre objets peuvent etre 
regis de diverses fa^ns dans les machines. Parmi elle, Texemple choisi utilise 
les mecanismes et modalites r6gis par une architecture d'objets distribu6s, 
I'axchitecture CORBA en I'occurrence. Dans le domaine de llnformatique 

10 distribute, I'architecture CORBA permet de sp^er des interfaces de 
services informatiques indtpendamment des foumisseurs et des langages 
mettant en oeuvre ces services. La specification des interfaces est faite k I'aide 
dhin langage neutre de description d'interface connu sous le nom de langage 
IDL (Interface Definition Language) defini aussi par le groupement OMG. Ce 

IS langage dtfinit les firontidres d'un composant que constitue un objet gtrt, 
c'est-&-dire les interfaces contractuefles du composant avec des clients 
potentiels. 

On a vu que l^ntegrateur 51 d'agents sert dlnterfaces entre la 
plate-forme 20 et les agents correspondants 17b de Tarchitecture CORBA. 

20 La figure 4 iUustre la structure d'une architecture CORBA 90 en 

liaison avec la plate-forme 20 par llntermediaire de llnt^ateur d'agent 51 
de type CMIP/CORBA. L'architecture CORBA 90 comprend : un courtier 91 
de requetes d'objets ou courtier ORB (Object Request Broker) dtfinissant un 
bus des objets (X)RBA ; un ensemble 92 de services CORBA dtfinissant les 

25 infirastructures d'objets au niveau syst^me qui ttendent le bus ; un ensemble 
93 d'appUcations CORBA ; un ensemble 94 d'installations CORBA (CORBA 
facilities) dtfinissant les infrastructures horixontales et verticales qui sent 
utilisees directement par les objets d'afifaire (business objects) ; et un 
compilateur IDL 95. 

30 (^mme il a ete dit en introduction, le precede connu de 

gtotration d'un module de base MIB consiste & utiliser un fichier de 
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description IDL tel quindique dans Tannexe IB a la presente demande, qui 
fait partie de la description et k appliquer le fichier k un g6n6rate\ir 52 pour 
obtenir une partie dudit module, 

Pour la realisation du generateur 52, pn connait plusieurs 

5 algorithmes de conversion, notamment les algorithmes d'administration 
interdomaine et connus sous le nom JIDM (Joint-Inter-Domain 
Management) issus du groupement OMG. Cependant, ils ne suffisent pas 
pour obtenir une version complete et exploitable en Ian gage GDMO. Cette 
insuffisance est due au fait que des notions conceptuelles pouvant etre 

10 decrites en langage GDMO ne peuvent pas Tetre en langage IDL. Ces notions 

sont notamment : 

- la definition des attributs de nommage» 

- des ri^es de construction d'arbres conntis sous le nom de liens 
de nommage et plus ordinairement name-binding, 

15 - I'allocation d*identifieurs d'objets, et 

. I'utilisation d'une mSme description d*attribut dans des^ 

interfaces dififerentes. 

La solution k ce probldme consiste k ajouter au fichier de 
description IDL de Tannexe IB des commentaires pour la conversion, tels que 

20 ceux illustr^ dans Tannexe lA. Selon I'exemple de Tannexe 1, les 
commentaires de Tannexe lA sont contenus dans une zone de commentaires 
solidaire du fichier de description IDL de Tannexe IB, la zone de 
commentaires pouvant pr6cMer ou suivre la description EDL. Dans ce cas, la 
zone se distingue des autres commentaires de la description IDL (annexe IB) 

25 par une marque, en Toccurrence la marque GEN. Selon une variante possible, 
les commentaires de Tannexe lA pourraient etre conteniis dans un fichier 
similaire k la zone iUustr^ mais independant du fichier de description IDL. 
Dans ce cas, il suffit d'appeler le fichier de commentaires pour completer la 
description IDL. Ainsi, la description IDL pent toujours etre pass^e au 

30 travers du compilateur IDL 95, avec les memes r^sultats, puisque la syntaxe 
du langage n^est pas modifi^. 
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La figure 5 illustre schematiquement le proc6d6. Le bloc 100 
comprend le fichier constitue du fichier de description IDL 101 illustr^ dans 
I'annexe lA et la zone de commentaires 102 illustre dans I'annexe IB. Le 
fichier 100 est applique k I'entree du premier generateur 52 pour generer le 
module 19 de base MIB. Le module 19 est done un fichier de description en 
langage GDMO. U module 19 est ensuite int6gr6 dans la base MIB. En 
pratique, dans I'exemple illustr^. l*integration du module 19 dans la base 
MIB est faite par compilation du module 19. La compilation est faite id par le 
compilateur GDMO 55 illustr^ dans la figure 2. Le module 19 est directement 
assimilable par le compilateur 55. Le compilateur 55 a pour nom gdmoc dans 
le produit OpenMaster de I'exemple consider^. II prend la description GDMO 
du module 19 en entree, en verifie la syntaxe et entre cette description dans 
la base MISS 42 de la figure 2 pour rendre disponible la description aux 
services 40 et aux applications 31 de la plate-forme 20. 

La figure 5 illustre aussi un proc6d6 en resultant pour la 
generation automatique de lintegrateur 51. Get int^ateur tel quiHustr^ 
sert a la conversion du langage IDL en protocole CMIP. Un agent integrateur 
CORBA 17b de la figure 2 est forme selon la technique anterieure, qui 
consiste k appUquer le fichier de description IDL 101 de I'annexe IB k I'entree 
du compUateur IDL 95. Une premiere partie 51a de l"int6grateur 51 est faite 
aussi k partir du compilateur 95. En fait, le compilateur 95 foumit une partie 
dite "skeleton" k I'agent CORBA et une partie dite "stub" k lint^grateur 51 
pour en constituer la premiere partie 51a. Une seconde partie 51b de 
l*int6grateur 51 est aussi faite selon la technique ant^rieiire, qui consiste k 
appliquer le module 19 de description GDMO au second genirateur 53. 
adapte k la g6n6rattion automatique d'integrateur d'agent k partir d*une 
description GDMO. cet outil 6tant appel6 OPAUADK dans le produit 
OpenMastei«. A noter toutefois que dans la technique anterieure. le module 
GDMO etait celui complete manuellement alors que dans IHnvention, il est 
gen^re en entier automatiquement. Selon llnvention. une troisieme partie 
55c de I'integrateur 51 est faite simplement et automatiquement k partir du 
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fichier 100 au moyen du troisi^me generateur 54, Le g6n6rateur 54 convertit 
le langage IDL du fichier 100 en un langage, par exemple C et/ou C++ qui 
sert a faixe un lien entre la partie 56a generie k partir du langage IDL et la 
partie 56b generee k partir du langage GDMO. 

5 Les commentaires illustr^s en annexe lA sont donn^ h titre 

indicatif et vont maintenant etre commentes. On a vu que la marque GEN est 
ajoutee au debut d'un commentaire pour etre interpretee par les g6n6rateurs 
52 et 54 comme d6but de commentaire. Les commentaires se composent de 
clauses ayant chacune leur signification pour le g6n6rateur 52. Une dause se 

10 compose d'au moins un mot cle s'appliquant k au moins un attribut qui le 
suit. Les clauses illustrees en annexe sont classees en plusieurs types qui ont 
et6 num^rot^s par les lettres A-E en italique et entre parentheses dans le seul 
but de fadliter leur pr^ntation. Cette pr^senUdon est faite aussi en 
reference h Tannexe 2 4 la prdsente description et en en faisant partie. 

15 L'annexe 2 donne simplement une liste explicative des types des clauses 
utilisees, ici A-H. 

Dans Tannexe lA, la clause de type A se compose du mot cl6 
METHOD.TOJ^TTRIBUTE smvi d*une methode, ici getjabel, et d'un 
attribut, id label Selon I'annexe 2, cette clause indique aux g6n6rateurs 52 et 

20 54 de convertir la methode getjabel en Vattribut UxbeL On notera que le 
convertisseur 52 de services CMIS ne generera aucun service M-ACTION 
mais que les generateur 52 genereront Tattribut spedfie. En d*autres termes. 
un dause du type (A) comprend un mot de (METHOD.TOj^TnUBUTE), 
une premidre caract^ristique representative du nom d'une methode et une 

15 seconde caracteristique representative d'un attribut, le mot de indiquant au 
generateur de convertir ladite methode en ledit attribut. 

Dans Tannexe lA, la dause de type B a le mot de 
MULTIPLE.DECLARE, qui signifie aux generateurs 52 et 54 quHls vont 
trouver une premiere interface induant I'attribut qui le suit, id "hostname" 

30 et une seconde interface induant aussi cet attribut n est 4 noter qu'en 
langage GDMO il est possible d'utiliser la meme definition d'attribut dans des 
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dasses differentes d'objets geres (dasses MOC). Ainsi. quand les g6n6rateurs 
trouvent la premiere interface, ils g^n^rent une premiere dasse MOC k partir 
de cette premiere interface et. de meme, quand les gdn6rateurs trouvent la 
seconde interface, ib generent une seconde dasse MOC h partir de cette 
seconde interface. lis utilisent done le meme attribut, id "hostname" dans le 
langage GDMO. En bref, dause du second type B comprend un mot 
(MULTIPLE_DECLARE) et un atthbut. le mot de indiquant au g6n6rateur 
de generer des dasses d'objets a partir dudit attribut. 

Dans les commentaires de I'annexe lA. la dause de type C a le 
mot d6 IGNORE, qui signifie aux gfeerateur de ne pas traduire le terme IDL 
qui le suit. U terme peut etre notamment un nom d"interface, un nom 
d'exception. un nom d'attribut et un nom de methode. Dans Texemple illustr6. 
le terme est un attribut nomm6 "ActualAttributeValue^t". En d'autres termes, 
les ginerateurs ne modifient pas le langage IDL pour la conversion. Ce mot 
d6 ofifre I'avantage de ne pas generer des choses inutUes dans la description 
GDMO. cela sans toucher au fichier de description IDL. 

U dause de type D a le mot d* TYPEDEF. qui indique aux 
generateurs 52 et 54 qu'il faut remplacer le premier mot qui le suit, 
representatif d'un type du langage GDMO, id 'Inter/aeeDer. par le second 
mot representetif d'un type du langage IDL, id 'OhjedT, normalement defini 
par une partie code dans le fichier de description de I'annexe IB, cette partie 
de code commen^t id par un terme nomm6 "indude" et ref(§renc6 par le 
caractdre "#". Cette dause permet de faire des synonymes entre les deux 
langages correspondants. En fait, cette dause est un moyen de dSfinir un 
type de donn^ utilis6 en langage IDL k partir du type de base. Cette 
definition est normalement faite par le verbe "typedeT du langage IDL et est 
import^e dans le fichier de description k I'aide des termes "indude". Cette 
dause s'explique par I'incapadte des generateurs de I'exemple illustr^, pour 
des raisons de limitations imposees par la realisation de ces generateurs, de 
chexcher les termes "indude" dans le fichier de description IDL. Comme la 
version courante des generateurs utilises dans I'exemple choisi ne gSre pas 
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les clauses de precompilation qui commencent par le caract^re "#" daas le 
6chier de descriptioii IDL de I'annexe IB, il a et6 ajout^ au fichier de I'annexe 
lA du code qui est present avec les termes "include" et n6ccssaire k la 
conversion au debut du fichier de description de I'annexf IB. En outre, dans 

5 le fichier de description de I'annexe IB. il est ajout^ une premidre marque 
suivi d'un terme non defini, id 'Mifdef FORJjENERATOR.TIME' et une 
seconde marque "#endif' (non illustr^). Ainsi, le compilateur 55 de la figure 
2 ignore ce qui est entre ces deux marques puisque le terme 
"FORjGENERATORJITME " n'est pas defini. Dans le compilateur. le 

10 pr^processeur (non illustr^). qui g^ndre du code C++ k partir du fichier de 
description. 6jecte la partie entre les deux marques alors que les deux 
g^nerateurs 54 et 55 vont les prendre en compte. En d'autres termes, on peut 
dire que si les gen^rateurs 52 et 54 ne g6rent pas des clauses de 
pr^mpilation, une clause de troisidme type (D) indut un mot d6 

15 CTYPEDEF) et deux mots, le mot d6 indiquant aux generateurs 52 et 54 qull 
faut remplacer Tun (InterfaceDef) des deux mots, repr^ntatif d'un type 
dudit module, par I'autre mot (O6;ec0 repr6sentatif d'un type du langage 
donnS IDL normalement defini par une partie de code (sous #indude) dans le 
fichier de description. 

20 Les dauses de type E dans les commentaires de I'annexe lA sont 

relatives aux liens de nommage. appeles name-binding. (3es dauses sont dues 
au fait qull n'y a pas de liens de nommage entre dasses en langage IDL mais 
qu'il en existe en GDMO. Cette dause permet ainsi d'introduire des liens de 
nommage name-binding dans une definition. Les dauses de type E 

23 compiennent trois mots d^ SUPER, SUBORD et NAME, suivis 
respectivement de mots (caract^ristiques d'objets, attributs, etc.). Le mots d6s 
SUPER et SUBORD ddsignent respectivement les dasses sup^rieures et 
subordonn^ d'objets et le mot d^ NAME designe I'attribut de nommage de 
la dasse subordonn^. Par exemple, la dause "SUPER orb SUBORD 

30 AgentSystem NAME hostname" indique qu*une instance de la dasse 
"AgentSystem" peut se trouver sous, ou etre contenue dans, une instance de 
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la dasse "orb" et qu'elle est nominee, en tant qu'attribut utilise pour le nom 
RDN, avec Tattribut "hostname" qui appartient a la classe "AgentSystem". En 
d'autres termes, une clause de quatri^me type (E) comprend trois mots cl6s 
(SUPER, SUBORD, NAME correspondant respectivement a trois 

5 caracteristiques (orb, AgentSystem, hostname)* deux des mots cl6s designant 
par leurs caracteristiques correspondantes deux instances de classes 
respectivement sup^rieure et inferieure et le troisieme mot cl6 d^gnant par 
la troisidme caract6ristique I'attribut de nommage de la classe subordonnee. 

Les clauses de types F et G de Tannexe 2 sont des clauses 

10 introductives. Ainsi. la clause de type G sert k nommer le module GDMO 
genere par le generateur 54 et la clause de type H sert k nommer le module 
ASNl gen6r6 par le g6n6rateur 55. 

La clause de type H de Tannexe 2 nScessite les observations 
preliminaires suivantes. Tous les objets s6mantiques GDMO g^nMs QAOC, 

15 NameBinding, Package, Attribute) sont identifies par des identifieurs d'objets 
(Object roentifiers) tels que definis par la norme ASNl. Ces identifieurs sont 
des suites d'entiers reprenant im meme prefixe. Par exemple» si on aUoue la 
suite "1 3 12" comme prefixe, on allouera automatiquement dans la 
generation automatique les identifieurs "1 3 12 1 "1 3 12 1 2". "1 3 

20 12 1 3", "1 3 12 1 4", pour identifier les classes MOC, puis les 
identifieurs "1 3 12 2 "1 3 12 2 2\ "1 3 12 2 3*, "1 3 12 2 4*. 
pour identifier les liens de nommage name-binding, etc La clause de type J 
pennet de demander aux generateurs 54 et 55 de prendre un prefixe different 
de ceux definis precedemment. Selon notre exemple, la clause "OID.TAG 15** 

25 demande au g^n^rateur de changer le prefixe prSc^dent, id "1 3 12** en **! 3 
15".En fait. Jes identifieurs sont gSneres k I'aide du prefixe, qui est allou6 
dans le syst^me d'administration 10 pour le systime COBA et auquel est 
ajoute un entier suppl^mentaire, le nombre 15 dans Texemple illustr6. Get 
entier supplementaire sert k distinguer des generations en langage IDL entre 

30 elles et done, k distinguer entre eux des modules de base MIB differents. 
Ainsi. sll existe plusieurs types d'agents implementant des modules 
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difKrents de base MIB. U est possible de voir tous ces agents dans la base 
MIB du syst^me d'administration 10. En d'autres teraes, si les objets sont 
identifies par des identifieurs (OID) ayant un meme pr^fixe. une clause de 
cin<iuidme type (H) comprend un mot de (OID.TAG) et un entier (15). le mot 
indiquant au g^n^rateur de prendre un prefixe diff(§rent et d^fini par ledit 
entier. 
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ANNEXE lA 



10 



15 



20 



25 



30 



35 



(zone de commentaires) 



II ^ 

//CEN: METHOD_TO_ArrRIBUTE get^labcl labd 

(A) 

II 

//GEN: MULTIPLE.DECLARE hostname 
//GEN: MULTIPLE^DECLARE value 

// 

//GEN: IGNORE ActuaiAnhbuteVaiueJ 
//GEN: IGNORE AllnbuteReferenceJ 



//- 



//GEN: TYPEDEF InterfaccDeT Object 
//GEN: TYPEDEF cvoit.typc.schcfna J string 
//GEN: TYPEDEF AttributeDef Object 
IIQEt^: TYPEDEF OperationDcf Ol^ect 



(B) 



(Q 



(D) 



//- 



//name-bindings : 

(E> 

II 



//GEN: SUPER top SUBORD oib NAME orb.name 

//GEN: SUPER ofb SUBORD Gateway NAME gateway.name 

// 

//GEN: SUPER oib SUBORD AgentSystem NAME hostnanie 

//CXN: SUPER OfbixServtr SUBORD OrbixORBCoreSegment NAMEbbd 

//GEN: SUPER OibixScfver SUB(^ OibixBOAScgment NAME label 

//GEN: SUPER OibixSefver SUB(XU> CORBAAppikatk>nObyect1VpeC^ 



//GEN: SUPER OibixORBCorcSegment SUBORD OfbixConnection 
//GEN: SUPER CORBAApplkaticnObjectTypeCMO SUBORD 
CORBAAppltcationObjectlnstanceCMO NAME label 



//- 



NAME label 
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ANNEXE IB 



5 


(Fichier <k description IDL) 






nnciude <ofD.Mii> 






iindude <IRD&.kl> 






fincnide <Upcrt/i.KU> 




10 


#i]idude <lnterOr.id> 






#iiiciu(knime.idl' 






#i]iclude 'Maming.kfl* 






//essai 






//findude TvcntManagementidl* 




15 


#iidcfF<»_GENERATOR,TIME 






module TimeBase { 






smia ulongk>ng( 




20 


unsigned long tow; 






unsigned tong high; 

}; 





25 
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ANNEXE2 



CLAUSES DE GENERATION 

Usage : gdmo fik.idl > fik gdmo 

//GEN: GDMO_MODULE_NAME jltAdin 

Sp6dtk le nom du module GDMO gdnM (par d^faut : 'orbAdm' 

Toutes les interfaces tiaduites soot dddarte en un seul module GDMO. 

r 

AnentkMi : oette clause doit toe plac^ devant tome instruction IDL. 

(Le g6ndrateur ne traduit pas les dtf nitions de module IDL en dtfinitkms correspondantes en GDMO, 
mais crtc seuleroent on module GDMO). 

//GEN: ASN1.M0DULE_NAME Idl2 (G) 

-> nom do module ASNl gfoM (par ddfaut : Idl*) 

Atlentioo : cette clause doit tet plac£e devant toute instniction WL. 

//GEN:OID.TAClS ^ 
-> La valeur pour te composanl idemifieitf d'obfet OID associ^ i *coite 
Ptnnet tfavoir diiKrentes gfndrations poor utiltser difKients identifieurs OlDt ... 

//GEN: METHOD.TO_ATTRIBUTE gct_labcl label W 

-> U mAhode 'get.label* est traduite en Pattribut label* 

La syntaxe retoumde par la mahode est utilisfe comme type d'attribut. 

Aucune m-action est gteMe pour la mfthode, seulement rattribut spicifid 

//GEN: MULTIPLE.DECLARE hostname (B) 
-> Quand un mtoie nom d'attrflmt est utilise dans difHrentes inierfaces IDL, ceci avertit le gfndrateur de 
pioduire seulement une dtf nttion d'attribut GDMO. 

//GEN: IGNORE EventSchemaMetaDef <Q 
-> Sptotie que rinterf^ donn^e n'a pas k etre traduite en GDMO. 

//GEN: TYPEDEFInter&ceDef Object (D) 
-> Permet de ddinir un type qui est normalement ddfini a\xc le terme 'include*. 
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//GEN: SUPER root SUBORB AgentSystem Name hoslnamc (E) 
-> lien de nommage name-binding k Cutset 

Spdcifie : classes (fobjets sup^euics et subordonndcs (ou noms (fintcrfaoe qui soitt i tiaduire en noms 
MOC^ 

*roo(* peiK etre spddfi^ pour U classe MOC sous la racine de la MTB. 
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Revendications 

1. Procede de generation automatique d'un module (19) d'une 
base d'infonnations d'administration (MIB) d'une ressource informatique (11) 

5 representee par objets et incluant une architecture d'objets distribu6s 
(CORBA) selon un langage donne aDL), consistant k faire un fichier 
(annexe IB) de description d'interface dans le langage donn6 et k appUquer 
ledit fichier k des moyens de generation automatique (52) pour obtenir une 
partie dudit module, caracterise en ce qu'il consiste k ajouter audit fichier de 

10 description un fichier (annexe lA) de clauses de generation automatique, une 
clause comprenant au moins un mot cle determinant un mode de generation 
et au moins une caracteristique sur laquelle porte un mot cle, et k appliquer 
le fichier de clauses auxdits moyens de g6n6ration pour completer ledit 
module. 

15 2. Procede selon la revendication 1, caract6ris6 en cc que le 

fichier de clauses et le fichier de description ne forment qu'un seul fichier 
(100), I'un (annexe lA) des deux fichiers etant distingue de I'autre par une 
marque (GEN)- 

3. Procede selon la revendication 1 ou 2, caracterise en ce qu'une 
20 clause d'un premier type (A) comprend un mot cl6 
(METHODjrOjVlTRIBUTE), une premiere caracteristique representative 
du nom d'une m^thode et une seconde caracteristique representative d'un 
attribut, le mot cl6 indiquant aux moyens de generation de convertir ladite 
methode en ledit attribut. 
25 4. Precede selon I'une des revendications 1 a 3, caracterise en ce 

qu'une clause d'un second type (B) comprend un mot cle 
(MULTIPLE_DECLARE) et un attribut, le mot cie indiquant au generateur 
de generer des classes d'objets k partir dudit attribut. 

5. Procede selon Tune des revendications 1 & 4, caracterise en ce 
30 qu'itne clause de troisieme type (Q comprend un mot cle (IGNORE) et une 
caracteristique, le mot cle indiquant aux moyens de generation d'ignorer 
ladite caracteristique. 
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6. Proced6 selon Tune des revendications 1 a 5. caracterise en ce 
les moyens de gen6ration ne gerant pas des clauses de precompilation, une 
clause de troisieme type (D) inclut un mot cle (TYPEDEF) et deux mots, le 
mot cle indiquant aux moyens de generation qu'il faut remplacer Tun des 

5 mots (InterfaceDef) par I'autre mot (Object) representatif d'un type du langage 
donne normalement defini par une partie de code (sous #include) dans le 

fichier de description. 

7. Proced6 Sfelon Tune des revendications 1 a 6, caracterise en ce 
qu'une clause de quatridme type (E) comprend trois mots cles (SUPER, 

ID SUBORD, NAME correspondant respectivement a trois caracteristiques (orb, 
AgentSystem. hostname), deux des mots cles designant par leurs 
caracteristiques correspondantes deux instances de classes respectivement 
sup^rieure et inferieure et le troisieme mot cle designant par la troisieme 
caracteristique I'attribut de nommage de la classe subordonnee. 

15 8. Procede selon Tune des revendications I a 7, caracterise en ce 

que les objets etant identifies par des identifieurs (OID) ayant un meme 
prefixe, une clause de cinquieme type (H) comprend un mot cle (OID.TAG) et 
un entier (15), le mot cle indiquant au generateur de prendre un prefixe 
different et defini par ledit entier. 

20 9. Procede selon Tune des revendications 1 a 8, caracteris6 en ce 

que les moyens de generation comprennent en outre un generateur (54) po\ir 
la generation automatique d'une partie (51c) d'un integrateur d'agents 
d*administration (51). 

10. Systdme d'administration (10) d'une ressource informatique 

25 (11) representee par objets definis dans une base d'informations 
d'administration (MIB) incluant un module, le systeme d'administration 
incluant au moins un processeur (14) et des moyens de memoire (15) et la 
ressource informatique incluant une architecture d'objets distribues (CORBA) 
selon un langage donne (IDL), caracterise en ce qu'il met en ceuvre au moyen 

30 d'au moins ledit processeur (14) le procede defini par Tune des revendications 
precedentes. 
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